[Thorsten Froehlich talks about cleaning up the way the camera works, and I
think this deserves a new thread.]

Thorsten,

Cleaning up the way the camera works sounds very interesting, and like a
good idea!

However, there's a few things I don't understand.

You say that full backward compatibility will be preserved - I presume
that's only when using the #version directive? It won't be possible to clean
up the camera mechanism and at the same time make it support all the same
things, so there'll have to be an "old" camera mechanism for #version <3.5
and a new one for #version >=3.5 which isn't 100% backwards compatible.
Isn't that what you mean too?

You also say that the order dependency will not and cannot be removed. I
don't understand either.
It won't be possible to make a camera mechanism that's easy to understand if
it's order dependent. There's nearly infinitely many order combinations in
which the parameters can be specified, and it isn't possible to explain the
effects of them all. Making the order of the parameters independent will
make it easier to understand.
And I think that it *is* possible to make it order independent. Just store
the camera parameters in dedicated values, and only when the entire scene
code has been parsed create the camera from those values using a predefined
order of calculations.

In most cases the camera will still work the same way as before, as most
people have followed the hints in the documentation about specifying the
look_at in the end etc., which follows an implied "correct order" to specify
the settings. Only in a few cases it will work differently.

I'm not entirely sure that's the right way to go, but I'd like to hear
comments about it.

I have thought out many more details about how the camera could work, but
I'll take one step at a time...

> Some of the bug reports regarding camera suggest users
> magically expect POV-Ray to guess which of two (both
> logical) models of thinking they use and adjust the
> behavior of the camera.

I'm not sure which two models you're referring to. Could you explain...?

> It would be good to have a short list of all keywords
> that are supported by a specific camera type and if
> they had to appear before or after the camera type was
> specified.

I'm not sure if you're talking about the current behavior or the wished
future behavior.

> If you could post a draft of such a short summary here
> and other would the complete it so there is a complete
> list of what behaviors users expect and which they don't
> expect (both exist in cameras up to 3.5 beta 9)

But many users expect the camera to work in a strange way in some cases,
because it does. Wouldn't it be better to find out which behaviors users
would find logical?

> I would be very happy to engineer the camera parsing code
> to exactly match user expectations, without the nasty side
> effect that currently exist.

I'm not quite sure how big changes you're talking about. Which is it closer
to: "fix a few of the worst unexpected behaviors" or "complete rewrite with
new, logical, predictable behavior"

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message